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Abstract 


The  VICTORIA  Class  Submarines  (VCS)  are  subject  to  a  continuing  program  of  technical 
upgrades.  One  such  program  is  replacing  the  Fire  Control  System  (FCS)  displays  and  re -hosting 
the  system  on  linux-based  servers.  As  part  of  this  technical  refresh,  Defence  Research  and 
Development  Canada  -  Atlantic  has  been  asked  to  provide  input  in  the  form  of  requirements  that 
might  be  satisfied  by  the  addition  of  content  to  an  anticipated  10%  extra  screen  area.  It  is 
expected  that  these  requirements  would  be  used  to  assist  in  the  evaluation  of  proposed 
design/system  solutions.  To  derive  these  requirements  a  cognitive  work  analysis  was  carried  out 
on  the  basis  of  two  interview  sessions  with  a  total  of  nine  subject  matter  experts.  A  variety  of 
different  methods  were  used  to  identify  requirements  at  a  level  that  do  not  impose  a  particular 
design  solution.  A  total  of  30  requirements  were  generated  covering  a  variety  of  different 
potential  design  directions. 
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Executive  summary 


Requirements  for  VICTORIA  Class  Fire  Control  System:  Contact 
Management  Function 

Tab  Lamoureux;  Heather  Colbert;  July  2014. 

Introduction:  The  VICTORIA  Class  Submarines  (VCS)  are  subject  to  a  continuing  program  of 
technical  upgrades.  One  such  program  is  replacing  the  Fire  Control  System  (FCS)  consoles, 
which  have  become  un-maintainable.  The  new  multi-function  consoles  have  been  specified  to 
provide  commonality  with  other  boat  consoles  and  are  expected  to  have  approximately  1 0%  more 
screen  area.  DGMEPM(SM)  is  expecting  the  contractor  will  propose  a  number  of  options  on  how 
this  screen  area  could  be  used,  and  requested  DRDC  Atlantic  to  look  at  developing  operator-task 
derived  requirements  that  might  be  used  to  help  assess  the  options.  Since  solution  independent 
requirements  were  desired  it  was  decided  that  the  use  of  cognitive  work  analysis  (CWA)  would 
be  appropriate.  Since  DGMEPM(SM)  has  not  used  this  technique  before  it  was  decided  to  do  an 
initial  trial  on  a  limited  set  of  FCS  functions  in  FY  12-13. 

Results:  Under  contract  to  DRDC  Atlantic  a  cognitive  work  analysis  (CWA)  was  carried  out  on 
the  Sensor  Analysis  Console  (SAC)  which  is  one  of  the  three  consoles  that  make  up  the  Fire 
Control  System.  Data  was  collected  on  SAC  operation  in  two  interview  sessions  with  a  total  of 
nine  subject  matter  experts.  Data  from  the  first  session  was  used  to  develop  an  initial  CWA 
model.  This  model  was  then  presented  to  the  second  session  for  verification  and  extension.  A 
variety  of  different  methods  were  used  to  extract  console  requirements  from  the  analysis 
techniques.  A  total  of  30  requirements  were  generated  covering  a  variety  of  different  potential 
design  directions. 

Significance:  The  developed  requirements  provide  a  solution-independent  set  of  criteria  which 
may  be  used  both  to  assess  proposed  solutions,  but  also  to  drive  potential  solutions  to  improve 
operator  workload  and  efficiency.  The  requirements  in  this  study  are  fairly  high-level  and  are 
biased  toward  the  cognitive  tasks  of  current  operators  and  work-flow.  The  results  also  are  based 
upon  the  study  of  only  one  of  the  three  consoles  in  the  system.  However,  even  from  this  limited 
study  a  number  of  requirements  were  found,  that,  if  met,  could  significantly  improve  operator 
efficiency. 

Future  plans:  As  resources  permit,  the  other  two  consoles  in  the  system  will  be  added  to  the 
CWA  models  and  assessed  for  additional  requirements.  In  addition,  the  whole  system  will  be 
assessed  to  determine  a  set  of  system  level  requirements. 
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1  Introduction 


This  section  describes  the  background,  objectives  and  scope  of  work  for  this  project. 

1.1  Background 

In  1998  Canada  purchased  the  VICTORIA  Class  of  submarines  (VCS)  from  the  Royal  Navy  to 
replace  the  OBERON  Class.  The  first  of  the  VICTORIA  Class  (HMCS  Victoria)  was 
commissioned  in  2000,  followed  by  HMCS  Windsor  and  Comer  Brook  in  2003,  and  HMCS 
Chicoutimi  in  2004.  As  part  of  the  purchase,  the  training  systems  associated  with  the  VICTORIA 
Class  were  also  provided  by  the  Royal  Navy. 

Contact  management  (also  known  as  track  management)  is  currently  conducted  on  the  Fire 
Control  System  (FCS)  consoles  using  software  developed  for  the  Canadian  Forces  under  a 
modernization  program  for  the  OBERON  submarine.  The  Royal  Canadian  Navy  (RCN)  is 
currently  upgrading  the  fire  control  system,  which  will  include  moving  the  software  to  new 
modular  consoles  which  have  screens  with  approximately  10%  more  screen  real-estate. 

The  fire  control  system  Life  Cycle  Maintenance  Manager  (LCMM)  is  interested  in  investigating 
options  for  the  use  of  this  additional  space.  Since  the  original  system  was  not  specifically 
designed  for  the  VCS,  specification  of  the  contact  management  task  within  the  VCS  is  required  to 
provide  a  baseline  for  options  analysis. 

In  previous  work  DRDC  Atlantic  has,  under  contract,  developed  cognitive  work  analysis 
elements  for  the  VCS  command  team  including  an  abstraction  layer  decomposition,  and 
hierarchal  goal  analysis  (HGA).  In  addition,  some  work  has  been  conducted  to  characterize 
periscope  operations.  While  some  elements  of  this  work  touch  on  the  contact  management  task 
they  were  not  directed  specifically  at  that  task. 

1 .2  Objective 

The  objective  of  the  current  work  is  the  development  of  engineering  specifications  for  the  task 
and  information  requirements  to  conduct  contact  management  in  VCS  operations. 

1.3  Scope 

This  work  is  intended  to  describe  the  VCS  contact  management  functions,  independent  of  the 
current  system  implementation,  in  order  to  provide  a  baseline  against  which  options  (amongst 
which  is  the  status  quo  system)  can  be  evaluated. 

The  analysis  focuses  on  the  development  of  contact  management  requirements  that  are 
compatible  with  end-user  needs  and  FCS  activities.  These  requirements  not  only  focus  on  the 
information  to  be  displayed  and  the  tasks  to  be  supported,  but  also  the  criteria  that  must  be  met 
so  that  the  Directorate  of  Maritime  Engineering  Program  Management  -  Submarines 
(DMEPM(SM))  can  evaluate  alternative  design  and  screen  options. 
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The  contact  management  function,  as  performed  by  the  Sensor  Analysis  Coordinator  (SAC;  also 
referred  to  as  the  Command  Display  Console  (CDC)  Operator),  has  been  selected  as  a  focus  for 
this  work.  Weapon  control  and  management  functions  are  not  addressed  in  this  work  except 
where  they  touch  on  the  contact  management  functions. 
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2  Method 


This  work  was  completed  using  a  Cognitive  Work  Analysis  (CWA)  approach.  The  following 
sections  describe  the  data  collection  sessions,  the  CWA  software  tool  used,  and  the  overall  CWA 
approach. 

2.1  Data  Collection  Sessions 

Two  sets  of  Subject  Matter  Expert  (SME)  interviews  were  completed  in  March  2013.  Initial 
Interviews  were  conducted  with  four  SMEs  (1  Combat  Systems  Engineer,  1  Maritime  Surface 
and  Subsurface  (MARS)  officer,  1  United  States  Navy  officer,  and  1  Naval  Combat  Information 
Operator  (NCIOP)  and  the  Program  Manager  in  Gatineau,  Quebec  on  March  4,  2013.  The  data 
from  these  initial  interviews  was  then  validated  and  expanded  upon  during  a  follow-up  session 
with  four  SMEs  (2  NCIOPs,  1  Naval  Communicator  (NAVCOMM),  and  1  MARS  officer)  at  the 
Submarine  School  in  Halifax,  Nova  Scotia  on  March  14,  2013. 

2.2  Tools 

A  CWA  software  tool  called  The  CWA  Tool,  version  1.0. 2.0  [1]  was  used  to  organize  and 
document  this  analysis.  The  CWA  Tool  was  developed  by  the  United  Kingdom’s  Defence 
Technology  Centre.  This  software  has  been  specifically  designed  to  support  the  development  of 
new  systems  that  support  the  cognition  of  the  operator.  In  particular,  the  software  supports  the 
integration  of  potentially  separate  functions  into  a  single,  coherent  system  design. 

2.3  Approach 

This  section  describes  the  CWA  approach,  as  well  as  the  approach  to  requirements  derivation. 

2.3.1  Cognitive  Work  Analysis 

During  the  SME  interview  sessions,  a  seven-step  decompositional  approach  to  the  CWA  was 
taken. 

The  first  five  steps  involved  the  creation  of  an  Abstraction  Hierarchy  (AH)  diagram  using  The 
CWA  Tool.  The  purpose  of  an  AH  is  to  describe  the  system  in  which  tasks  take  place,  without 
focusing  specifically  on  any  goal  or  activity.  The  AH  created  as  a  result  of  this  work  is  described 
in  Section  3.1.  The  AH  diagram  itself,  as  well  as  tables  indicating  the  links  between  nodes  at  each 
level  of  the  AH,  are  included  in  Annex  A. 

Table  1  explains  the  CWA  step,  the  information  gathered,  how  the  information  was  gathered  in 
the  SME  interview  sessions,  the  purpose  for  gathering  this  information  and  how  the  information 
is  represented  using  The  CWA  Tool. 
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Table  1:  Cognitive  Work  Analysis  Steps  One  through  Five 


Step 

Information 

Gathered 

How  information 
was  gathered  during 
SME  session 

Purpose 

Representation 
in  The  CWA 
Tool 

1 .  Identify 

Functional 

Purposes 

This  step 
identifies  the 
fundamental 
purposes  of 
the  system,  or 
the  reason  it 
exists. 

The  functional 
purpose  was 
identified  with  SMEs 

Noting  this 
information  helps 
to  ensure  that  any 
changes  to  the 
system  continue  to 
allow  the  system 
to  meet  the 
functional 
purpose. 

Top  level  of  the 
AH  diagram 

2.  Identify 
values  and 
priority 
measures. 

This  step 
identifies 
criteria  that 
can  be  used 
to  evaluate 
how  well  as 
system 
achieves  its 
purpose. 

SMES  were  asked  to 
identify  how 
effective  contact 
management 
performance  is 
characterized  and 
how  performance  can 
be  measured. 

This  step  helps  to 
identify 

performance  goals 
that  need  to  be 
met  or  exceeded 
with  any  changes 
to  the  system. 

2nd  level  of  the 
AH  diagram 

3.  Identify 
Physical 

Objects 

This  step 

identifies 

physical 

system 

components, 

as  well  as 

information 

components. 

SMEs  were  asked  to 
identify  all  the 
physical  and 
information 
components  that  are 
implicated  or 
involved  in  the 

current  contact 
management  task. 

Characterizing  the 
physical 

components  of  the 
system  helps  to 
identify  how 
changes  to  those 
components,  or 
related  processes 
impact  the  system. 

5th  level  of  the 
AH  diagram 

4.  Identify 

Object-Related 

Processes 

This  step 
identifies  the 
processes 
related  to  the 
physical  and 
information 
components 
of  the  system. 

SMEs  were  asked  to 
identify  physical 
system  functions  that 
are  performed  using 
the  physical  and 
information  system 
components. 

Characterizing  the 
physical  functions 
of  the  system 
helps  to  identify 
how  changes  to 
those  functions,  or 
related 

components  may 
impact  the  system. 

4th  level  of  the 
AH  diagram 
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Step 

Information 

Gathered 

How  information 
was  gathered  during 
SME  session 

Purpose 

Representation 
in  The  CWA 
Tool 

5.  Identify 

Generalized 

Purpose- 

related 

functions 

This  step 
identifies  the 
functions 
required  to 
achieve  the 
purposes  of 
the  systems. 

SMEs  will  be  asked 
to  identify  general 
functions  that 
describe  the  purpose- 
related  functions  of 
the  system. 

Characterizing  the 
purpose-related 
functions  in  a 
general  sense, 
helps  to  identify 
general  areas 
impacted  by 
changes  to  the 
system. 

3rd  level  of  the 
AH  diagram 

Steps  6  and  7  in  the  process  expanded  on  the  AH  to  identify  specific  situations  and  strategies  of 
interest  for  system  improvement.  Table  2  explains  the  CWA  step,  the  information  gathered,  how 
the  information  was  gathered  in  the  SME  interview  sessions,  and  the  purpose  for  gathering  this 
information. 


Table  2:  Cognitive  Work  Analysis  Steps  Six  and  Seven 


Step 

Information 

Gathered 

How  information 
was  gathered  during 
SME  session 

Purpose 

Representation 
in  The  CWA 
Tool 

6.  Identify 

Situations 

In  this  step 
possible 
situations  that 
need  to  be 
addressed  by 
the  system 
were 

identified. 

SMEs  were  asked  to 
identify  potential 
situations  that  arise  in 
using  the  system  and 
the  different 
functions  that  come 
into  play  for  each 
situation.  They  were 
also  asked  to  identify 
different  information 
sources  needed  to 
make  decisions 
according  to  the 
situation. 

Different 
situations  may 
require  different 
functions  from  the 
system.  Some 
functions  are 
applicable  to  a 
range  of  situations 
and  have 

significant  impact 
on  system 
performance. 

These  functions 
may  be  an 
appropriate  focus 
for  improvement 
when  updating  a 
system  because 
they  support  many 
different  anticipated 
situations. 

Contextual 

Activity 

Template 

(CAT) 
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Step 

Information 

Gathered 

How  information 
was  gathered  during 
SME  session 

Purpose 

Representation 
in  The  CWA 
Tool 

7.  Identify 
Strategies 

In  this  step 
the  variety  of 
techniques 
system 

operators  may 
use  to 
approach  a 
situation  were 
identified 

For  specific 
situations,  SMEs 
were  asked  to 
identify  alternate 
strategies  which 
could  be  used  to 
address  the  situation 
within  the  system. 

They  were  also  asked 
to  identify  different 
information  sources 
needed  to  make 
decisions  according 
to  the  strategy  used. 

Operators  may  use 
a  variety  of 
strategies  to 
approach  similar 
situations  within  a 
system.  Different 
strategies  may 
reveal  different 
needs.  Any 
changes  to  a 
system  must 
support  operators. 

Strategies 

Analysis 

2.3.2  Requirements  Derivation 

The  CWA  outputs  were  used  to  derive  requirements  for  the  FCS.  Requirements  were  derived  in 
several  ways: 

•  Direct  requests  from  SMEs  for  functionality  or  enhancements  were  noted  as 
requirements.  Where  possible,  these  were  mapped  to  the  CWA  AH,  CAT  and/or  the 
Strategies  Analysis; 

•  The  number  of  links  entering  the  object-related  process  level  from  the  physical 
objects  level  below  were  counted.  Those  object-related  processes  with  the  most  links 
were  potential  nexus  of  physical  objects,  and  requirements  to  address  them  might  be 
opportunities  to  integrate  physical  and  informational  entities  that  affect  the  contact 
management  task; 

•  The  number  of  links  entering  the  purpose-related  function  level  from  the  values  and 
priority  measures  level  above  were  counted.  The  purpose-related  functions  with  the 
most  links  were  potential  nexus  of  key  aspects  of  performance,  and  requirements  to 
address  them  might  directly  affect  overall  system  performance  at  the  contact 
management  task  by  addressing  the  key  performance  elements; 

•  Values  and  priority  measures  were  directly  addressed  through  requirements  for  the 
system  design  options; 

•  Object-related  processes  that  map  across  the  most  situations  listed  in  the  CAT  were 
also  considered  as  nexus  for  contact  management  activity.  Requirements  were 
developed  for  those  object-related  processes  that  mapped  to  the  most  situations,  and; 


6 


•  Requirements  that  suggested  themselves  from  the  different  strategies  adopted  by 
SMEs  to  achieve  the  object -related  processes  investigated  in  the  strategies  analysis 
were  also  included. 

All  requirements  derived  from  a  particular  part  of  the  CWA  were  validated  against  other  CWA 
components  to  ensure  that  there  was  some  convergent  validation.  Some  requirements  were  also 
validated  with  SMEs  at  the  Submarine  School  in  Elalifax  on  March  14,  2013. 
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3  Results 


This  section  presents  the  results  of  the  CWA  including  the  AH,  CAT  and  Strategies  Analysis. 
Requirements  derived  as  a  result  of  the  CWA  are  also  presented. 

3.1  Abstraction  Hierarchy 

The  AH  diagram  created  as  a  result  of  this  work,  as  well  as  tables  indicating  the  links  between 
nodes  at  each  level  of  the  AH,  are  provided  in  Annex  A.  The  following  tables  describe  each  node 
of  the  AH  according  to  the  five  AH  levels. 

Table  3:  Abstraction  Hierarchy  Nodes,  Level  1 — Functional  Purpose 


Node 

Description 

Information  Management 

Distributing,  receiving,  organizing,  reformatting  or 
otherwise  manipulating  or  working  with  information. 

Sensor  Coordination 

Activities  relating  to  coordinating  the  tasks  of  sensor 
personnel,  and  the  use  of  sensor  equipment. 

Submarine  Safety 

Activities  relating  to  avoiding  enemy,  preventing  collisions, 
or  otherwise  maintaining  the  wellbeing  of  the  ship  and  crew. 

Mission  Achievement 

The  objectives  of  the  mission  are  achieved,  including 
objectives  regarding  stealth  and  safety. 

Table  4:  Abstraction  Hierarchy  Nodes,  Level  2 — Values  and  Priority  Measures 


Node 

Description 

Maintain  appropriate  data 
update  rate  for  contacts 

Data  is  updated  at  an  appropriate  rate  to  allow  contacts  to  be 
identified  and  processed  and  tracked  in  support  of  submarine 
safety  and  mission  achievement 

Enter  all  required 
information 

No  information  (track  or  other)  required  to  achieve  the 
functional  purposes  is  omitted  or  overlooked. 

Contribute  to  prioritization 
of  contacts 

Contacts  are  prioritized  quickly  and  easily  according  to 
appropriate  parameters  (e.g.  threat  level,  proximity). 

Maintain  situation 

awareness 

Awareness  of  the  situation  is  maintained  including  tracks, 
ownship  and  environmental  parameters.  This  involves 
detecting  all  contacts  in  the  area  of  interest,  knowing  what 
the  contacts  are,  and  knowing  what  they  will  do  in  the  near 
future. 

Use  sensors  appropriately 

Sensors  are  employed  in  a  way  that  provides  the  greatest 
amplification  of  contact  identification  and  intent. 

Communicate  effectively 

Information  is  transmitted  in  a  timely,  accurate,  economical 
and  understandable  way. 

Do  not  contravene  critical 
safety  parameters 

The  system  must  assist  the  operator  not  to  overlook,  omit  or 
otherwise  contravene  critical  safety  parameters  take  place. 

Table  5:  Abstraction  Hierarchy  Nodes,  Level  3 — Purpose-Related  Functions 


Node 

Description 

Distribute  Information 

Ensure  that  information  is  provided  and  available  when 
needed  to  the  people  that  need  it. 

Maintain  Effective  Display 

Maintain  a  display  that  is  clear  and  accurate,  with  no 
redundant  or  secondary  contact  information. 

Coordinate  Activities  of 
Sensor  Team 

Prioritize  and  direct  the  activities  of  the  various  sensor  teams 
in  order  to  maximize  the  understanding  of  the  tactical 
situation,  as  appropriate  to  the  current  activities. 

Coordinate  with  FCS  Team 

Prioritize  and  direct  the  activities  of  the  FCS  team,  including 
Target  Motion  Analysis  (TMA),  in  order  to  maximize  the 
understanding  of  the  tactical  situation,  as  appropriate  to  the 
current  activities. 

Prioritize  Contacts 

Prioritize  contact  with  respect  to  the  danger  they  represent  to 
the  submarine,  likely  hostile  intent,  suspicion,  etc. 

Table  6:  Abstraction  Hierarchy  Nodes,  Level  4 — Object-Related  Processes 


Node 

Description 

Entering  Information  from 
Sound  Room 

Entering  information  received  from  the  Sound  Room  into  the 
tactical  display.  Typically  representing  information  that 
amplifies  the  simple  representation  of  a  bearing  line. 

Entering  Information  from 
Warner  Take  Procedure 

Entering  Information  from  Warner  Take  Procedure  into  the 
tactical  display.  Typically  representing  information  that 
amplifies  the  simple  representation  of  a  bearing  line. 

Entering  Bathy 

Information 

Entering  Bathy  Information  into  the  tactical  display 

Entering  Information  from 
LINK/Automatic 
Identification  System  (AIS) 

Entering  Information  from  LINK/ AIS  into  the  tactical 
display 

Entering  Information  from 
Periscope  procedures 

Entering  Information  from  Periscope  procedures  into  the 
tactical  display.  Typically  representing  information  that 
amplifies  the  simple  representation  of  a  bearing  line. 

Entering  Information  from 
RADAR/IFF 

Entering  Information  from  RADAR/IFF  into  the  tactical 
display 

Entering  Information  from 
Ranging  Manoeuvre 

Entering  Information  from  Ranging  Maneuvers  into  the 
tactical  display.  Typically  representing  information  that 
amplifies  the  simple  representation  of  a  bearing  line. 

Entering  Information  from 
Stem  Arc  Clearance 
Procedure 

Entering  Information  from  Stem  Arc  Clearance  Procedure 
into  the  tactical  display.  Typically  representing  information 
that  amplifies  the  simple  representation  of  a  bearing  line. 

Entering  Information  from 
Basic  Intelligence  (BINT) 

Entering  Information  from  BINT  into  the  tactical  display. 
Typically  representing  information  that  amplifies  the  simple 
representation  of  a  bearing  line. 

Entering  lat/long 

Entering  the  lat/long  position  of  the  ownship  into  the  tactical 
display 
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Enter  Information  from 
TMA 

Entering  contact  information  received  from  TMA  (e.g. 
speed,  course,  range  etc.) 

Declutter  Display 

Processing  of  tracks  including  removing  redundant  tracks, 
typically  those  tracks  that  are  opening  (becoming  distant)  on 
the  submarine. 

Correlate  Tracks 

Comparing  and  combining  tracks  as  necessary  when  they 
represent  a  single  entity.  Also  called  associating  tracks. 

Reassign  Track  Numbers 

Reassigning  numbers  as  necessary  (usually  after  a  ranging 
maneuver  or  stem  arc  clearance  procedure) 

Communicate 

Communication  in  any  form  (e.g.  verbal,  via  headset,  via 
shared  displays).  This  activity  includes  the  secretarial 
function  of  logging  verbal  commands,  especially  during 
emergency  situations,  such  as  damage  control 

Consider  contact  in 
relation  to  critical  safety 
parameters 

Consider  range,  bearing,  speed,  intent  against  emergency  go 
deep  envelope,  current  depth,  water  under  the  hull,  current 
activities,  etc. 

Table  7:  Abstraction  Hierarchy  Nodes,  Level  5 — Physical  Objects 


Node 

Description 

Low  Frequency  SONAR 

Sensor  within  the  sound  room 

Hi  Frequency  SONAR 

Sensor  within  the  sound  room 

Broadband  SONAR 

Sensor  within  the  sound  room 

Narrowband  SONAR 

Sensor  within  the  sound  room 

Active  Intercept  (Watcher) 

Sensor  within  the  sound  room 

Passive  Ranging  Sonar 
(PRS) 

Sensor  within  the  sound  room 

Searcher 

Sensor  within  the  sound  room 

Underwater  Telephone 

Sensor  within  the  sound  room 

Active  SONAR 

Sensor  within  the  sound  room 

ESM 

Electronic  Support  Measures  (ESM)  Sensor 

Bathy  Information 

Data  from  the  Bathy  system 

LINK 

LINK  system.  On  the  submarine  this  is  a  basic  LINK  and  is 
typically  passive. 

AIS 

Automatic  Identification  System.  Can  provide  a  lot  of 
amplifying  data.  Warships  may  not  provide  AIS  data. 

Attack  Periscope 

Provide  bearing  to  contact,  any  other  information  is  based  on 
visual  and  calculated  information. 

Search  Periscope 

Provide  bearing  to  contact,  any  other  information  is  based  on 
visual  and  calculated  information. 

GPS 

Global  Positioning  System  Coordinates 

RADAR 

Provides  range,  bearing,  course  and  speed  of  contacts. 

IFF 

This  provides  identity  information  for  radar  contacts.  The 
submarine  has  a  ‘receive  only’  capability. 

NAV  data 

Information  regarding  course,  speed,  depth,  etc.  of 
submarine.  This  is  automatically  entered  into  the  contact 
management  system. 
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Keyboard  (General) 

The  keyboard  input  device 

Keyboard  (Function  Keys) 

The  function  keys  on  the  keyboard 

Trackball 

The  trackball  input  device 

Display  (Time  and  Bearing 
Plot) 

The  main  display,  where  track  bearings  are  shown  over  time. 
Time  (now)  is  at  the  top  of  the  display  and  older  entries  are 
further  down  the  display. 

Display  (Cascading 

Menus) 

The  menu  structure  as  displayed  on  the  console 

Display  (Other  Pages) 

Pages  within  the  display,  other  than  the  time  and  bearing  plot 
or  cascading  menus 

Display  Element — Contact 
(Line) 

When  a  contact  has  been  tracked  by  a  sensor  for  a  time  its 
plot  of  readings  forms  a  line  of  symbols  (see  below). 

Display  Element — Contact 
Symbol 

A  contact  appears  on  the  display  coded  according  to  sensor 
(e.g.,  a  “+”  for  a  contact  detected  by  the  broadband  SONAR, 
a  triangle  for  a  contact  detected  by  the  flank  array,  a  square 
for  a  contact  detected  on  narrow  band  SONAR,  and  a  ‘#’  for 
ESM) 

Display  Element — Track 
Number 

Numeric  Track  Number 

Display  Element — text  box 

A  text  box  is  placed  at  a  point  in  time  to  form  a  log  of 
activities,  data  readings,  and  significant  events.  It  is  unclear 
if  think  bubbles  are  stored  in  a  formalized  way  that  allows 
them  to  be  used  for  analysis  and  trending  information  while 
aboard  the  submarine. 

Display  Element  (Zero 
Bearing  Line) 

The  zero  bearing  line  represents  true  north.  The  SAC  can 
click  on  the  bearing  axis  to  re -centre  the  time  and  bearing 
plot  on  the  chosen  bearing  (typically  that  of  the  submarine’s 
course). 

Display  Element 
(Waterfall) 

This  is  the  type  of  display,  which  grows  from  top  to  bottom 
with  time. 

Display  Element  (Cursor) 

The  “+”  cursor  which  is  controlled  by  the  trackball 

Information  Element 
(Course) 

Course  of  the  track. 

Information  Element 
(Range) 

Distance  from  ownship  to  track 

Information  Element 
(Type) 

The  type  of  track  (e.g.  merchant  vessel,  frigate  etc.) 

Draft  of  ship 

Depth  to  which  the  hull  of  a  surface  ship  intrudes.. 

Ship  Knowledge 

Knowledge  of  different  types  of  ships,  how  they  operate, 
what  speeds  the  move,  typical  course  lengths,  hazards 
around  them,  including  accompanying  aircraft,  etc. 

Information  Element 
(Track  Number) 

Number,  either  autogenerated  or  entered. 

Information  Element 
(Speed) 

The  speed  of  a  track 

Information  Element 
(Bearing  Rate — Fast,  Slow, 

Bearing  rate  relative  to  Ownship.  Bearing  rate  is  judged  by 
the  steepness  of  the  curve  on  the  time  and  bearing  plot.  The 
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FWD,  AFT  or  ZERO) 

steepest  part  of  the  curve  indicates  the  closest  point  of 
approach. 

Widget  (Bearing/Rate 
Computer) 

A  slide  rule-like  device  that  enables  seaman  to  quickly 
determine  reciprocal  angles,  angle  on  the  bow,  closing 
speeds,  etc. 

Tac  Board  (Range  of  the 
Day) 

Physical  display  within  the  Ops  Room  including  the  manner 
in  which  sound  is  propagating  due  to  water  temperature, 
salinity,  etc. 

Headsets  (Comms  System) 

The  interface  with  the  shipboard  communications  system. 

Checklists 

Written  or  Mental  checklists  used  to  assist  during  standard 
procedures. 

Orders 

Verbal  or  written  orders 

Priorities 

Including  contacts  of  interest,  operating  envelopes,  etc. 

Procedures/SOPs 

Written  documents  describing  standard  operating  procedures 
for  specific  situations.  Also  things  like  shipping  and  ferry 
schedules,  shipping  lanes,  etc. 

Depth  under  hull  (Keel) 

Depth  under  the  submarine  to  avoid  manoeuvring  into  the 
bottom. 

Emergency  go  deep 
envelope 

The  safety  bubble  around  the  submarine  at  which  point  the 
submarine  will  dive  to  avoid  collision  or  attack.  Must  be 
correlated  with  water  depth  under  the  hull. 

3.2  Contextual  Activity  Template 

The  Contextual  Activity  Template  (CAT)  allows  the  analyst  to  map  elements  from  the  AH  to 
different  situations  in  which  the  system  may  operate.  From  the  initial  meeting  with  SMEs  (March 
4,  2013)  the  following  19  situations  were  identified: 

•  At  Depth; 

•  At  Periscope  Depth; 

•  At  Surface; 

•  BINT; 

•  Entering/Leaving  Harbour; 

•  River  Routine; 

•  Passage  Routine; 

•  Blind  Pilotage; 

•  Transit  Routine; 

•  Ditching  Gash; 

•  Running  Opened  Up/Closed  Down; 

•  Blowing  Tanks; 

•  Snorting; 
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•  Mine  Laying; 

•  In  Shore  Operations; 

•  Underwater  Look; 

•  Special  Operations; 

•  Search  and  Rescue  (SAR),  and; 

•  Working  with  helicopters  or  Maritime  Patrol  Aircraft  (MPA). 

To  complete  the  CAT,  these  situations  were  analyzed  according  to  the  object-related  processes 
(as  identified  in  level  4  the  AH)  that  could  occur  during  that  situation.  During  the  second  SME 
session  (March  14,  2013)  the  SMEs  verified  the  situation  and  the  CAT  and  provided  the 
following  amendments: 

•  When  blowing  tanks  or  snorting  the  environment  is  too  noisy  to  effectively  use  any 
of  the  sensors  in  the  sound  room.  Although  the  SAC  position  is  still  manned  and 
critical,  the  primary  sensor  in  use  will  be  ESM,  the  periscope,  and  radar  (in  poor 
visibility)  supplemented  by  A1S  information  when  provided  from  the  Electronic 
Chart  Precise  Integrated  Navigation  System  (ECPINS)  display; 

•  When  entering  or  leaving  harbor  the  SAC  position  is  not  manned.  Contact 
management  is  performed  from  the  conning  tower,  visually  or  using  radar  (in  poor 
visibility); 

•  During  an  underwater  look,  all  information  coming  to  the  SAC  is  visual; 

•  An  incoming  toipedo  is  also  a  critical  situation  for  the  contact  management  function. 
During  this  situation  the  sound  room  is  constantly  passing  the  torpedo  bearing.  This 
information  is  going  straight  to  TMA  for  targeting  purposes,  and; 

•  When  working  with  helicopters  or  the  MPA,  the  submarine  does  not  specifically  plot 
aircraft,  since  their  tracks  are  generally  not  held  for  long.  Nevertheless,  the  contact 
management  function  continues. 

The  completed  CAT  is  included  in  0.  In  the  CAT,  the  columns  represent  situations,  and  the  rows 
represent  object-oriented  processes  (or  functions).  The  likelihood  of  occurrence  of  each  function 
during  each  situation  is  represented  graphically.  A  function  that  “can”  occur  during  a  situation  is 
indicated  by  the  dotted  region,  while  a  function  that  “typically”  occurs  is  indicated  by  the  box- 
and-whisker  diagram.  In  the  final  CAT,  the  following  processes  appear  to  be  most  generally 
applicable: 

•  Entering  information  from  the  sound  room; 

•  Correlating/associating  tracks  (a  primarily  mental  task,  see  Section  3.3); 

•  Considering  the  contact  in  relation  to  critical  safety  parameters;  and, 

•  Communicating,  especially  the  secretarial  function  of  using  the  keyboard  to  enter 
data  regarding  significant  events  on  the  submarine  (like  a  second  ship’s  log). 
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3.3  Contact  Management  Strategies 


The  strategies  analysis  allows  the  analyst  to  capture  different  cognitive  and  physical  strategies  the 
SME  might  adopt  to  achieve  a  particular  function  or  objective.  Following  the  first  SME  session  in 
Gatineau  (March  4,  20 1 3)  the  following  activities  were  identified  as  ones  for  which  SMEs  might 
use  different  strategies  depending  upon  the  context: 

•  Prioritizing  tracks; 

•  Managing  and  prioritizing  sensors; 

•  Correlating/associating  tracks; 

•  Reassigning  track  numbers; 

•  Decluttering  the  display; 

•  Entering  sensor  data; 

•  Communication;  and, 

•  Consider  contact  in  relation  to  critical  safety  parameters. 

No  specific  information  regarding  these  strategies  was  collected  during  the  first  SME  session. 
During  the  second  SME  session  the  participants  represented  two  different  trades:  NCIOPs  and 
NAVCOMM.  The  NCIOPs  learn  the  picture  compilation  task  from  the  very  beginning  and  have 
extensive  and  broad  knowledge  about  the  tasks,  the  sensors  involved,  and  the  system  vagaries. 
The  NAVCOMMs  come  to  the  contact  management  task  abruptly  when  assigned  to  a  submarine 
and  rely  more  on  external  support  tools  in  the  control  room  than  knowledge  of  theory  and 
practice.  Thus,  NCIOPs  tended  to  carry  out  tasks  mentally,  where  NAVCOMMs  used  other 
information  displays  within  the  control  room. 

The  strategy  information  collected  during  the  second  SME  session  is  provided  in  the  following 
sections. 

3.3.1  Prioritizing  tracks 

Generally,  SAC  operators  apply  the  following  schema  when  prioritizing  tracks: 

•  Highest  priority:  Torpedo  because  it  actively  seeks  to  destroy  the  submarine; 

•  Next  highest  priority:  fishing  vessel  because  it  is  hazardous  due  to  its  nets,  because  it 
drifts  and  a  bearing  cannot  be  taken  (Peace  Time); 

•  Next  highest  priority:  another  submarine  because  it  may  be  tracking  ownship,  thus 
jeopardizing  mission  achievement; 

•  Next  highest  priority:  aircraft  because  they  can  see  the  submarine; 

•  Next  highest  priority:  warships; 

•  Lowest  priorities:  merchant  ships  and  ferries,  because  they  are  predictable  and  rarely 
exhibit  dangerous  (i.e.,  threatening  or  erratic)  behavior. 
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With  the  exception  of  the  fishing  vessel,  anything  that  is  weapons  capable  is  prioritized.  Within 
this  prioritization  schema,  the  SAC  operator  will  also  prioritize  based  on  speed  of  the  contact  and 
range  to  the  contact.  The  faster  the  contact  and  the  closer  it  is,  the  higher  priority  it  will  be  made. 

If  the  mission  requires  that  attention  be  paid  to  specific  contacts  or  vessels  of  interest,  these  will 
also  be  made  a  high  priority,  as  will  enemies  in  a  warfare  situation. 

3.3.2  Interpreting  the  Time  and  Bearing  Plot 

During  the  second  SME  session,  personnel  stated  that  the  Closest  Point  of  Approach  (CPA)  for  a 
contact  was  indicated  on  the  time  and  bearing  plot  by  the  area  of  the  contact  curve  with  the 
highest  bearing  rate  change  (i.e.  the  most  horizontal  segment  of  a  contact’s  line  on  the  screen). 
When  asked  to  elaborate  on  how  to  extract  information  from  the  time  and  bearing  plot,  they 
replied  that  understanding  and  experience  contributed  to  expertise  in  interpreting  the  plot.  One 
SME  (NAVCOMM)  indicated  that  he  relied  heavily  on  the  Tactical  Plan  Display  (TPD). 

The  time  and  bearing  plot  has  a  key  marker:  the  0°  line  representing  true  North.  Contact  bearings 
are  plotted  in  relation  to  true  North,  as  is  the  submarine’s  course.  The  SAC  can  re -centre  the  time 
and  bearing  plot  to  make  the  submarine’s  course  (or  any  bearing  at  all)  the  centre  of  the  display. 
The  centred  bearing  then  has  the  remaining  360°  laid  out  to  the  right  and  left  (in  180°  halves). 
This  makes  it  easier  for  the  SAC  to  determine  bearings  relative  to  each  other,  including  relative  to 
the  ownship. 

The  time  available  and  the  preparations  made  for  this  SME  session  meant  that  we  were  unable  to 
explore  strategies  for  interpretation  further.  An  investigation  into  interpretation  would  probably 
need  to  involve  scenario-based  structured  interview  approaches  to  systematically  identify  the 
subtle  cues  and  associated  meanings  applied  by  SMEs  to  interpretation  of  time  and  bearing  plots. 

3.3.3  Managing  and  Prioritizing  Sensors 

In  most  situations,  the  sensors  that  are  controlled  by  the  sound  room  are  the  priority  sensors.  Of 
these,  the  broadband  sonar  is  the  main  sensor.  If  at  periscope  depth,  however,  the  visual  ‘ground 
truth’  picture  provided  by  the  periscope  is  prioritized.  If  visibility  is  poor,  but  the  submarine  is  at 
periscope  depth,  then  electronic  sensors  are  prioritized.  Given  the  ‘passive’  listening  aspect  to 
ESM,  this  is  more  likely  to  be  used  in  tactical  situations  (with  ‘listening’  sonar),  whereas  radar 
will  be  used  in  safety  situations.  With  respect  to  detection  ranges,  if  used,  ESM  would  likely 
detect  a  contact  first,  followed  by  the  sound  room,  then  the  periscope  (again,  if  used).  Depending 
on  the  contact,  the  periscope  may  detect  a  contact  before  the  sound  room  (for  instance,  in  the  case 
of  aircraft  or  drifting/quiet  entities). 

3.3.4  Correlating/Associating  Tracks 

Correlation  and  association  of  tracks  is  a  proactive  process  on  the  part  of  the  SAC.  When  a  track 
is  created  it  is  assigned  a  sensor  track  number.  The  SAC  will  allocate  a  master  track  number. 
Once  a  track  is  created  by  a  sensor  the  SAC  coordinates  further  cuts  against  that  track,  and  will 
direct  the  sensor  as  to  what  number  to  make  that  track.  In  the  specific  instance  of  the  broadband 
sonar,  the  SAC  will  give  the  track  a  master  track  number  and  will  direct  the  sonar  operator  to 


15 


track  that  contact  on  a  particular  channel  number.  This  approach  provides  a  verification 
mechanism  to  ensure  discussion  of  tracks  is  referring  to  the  correct  track.  The  master  track 
number  is  also  used  by  the  TMA  operator,  to  further  assist  the  clarity  of  communications  on  the 
submarine. 

When  a  different  sensor  picks  up  a  track,  the  SAC  will  consider  whether  it  is  coming  from  the 
original  track,  and  then  will  direct  the  sensor  to  make  that  track  the  required  track  number.  Thus, 
track  correlation/association  is  done  mentally  based  on  the  knowledge  of  the  SAC  of  the  relative 
bearings  of  contacts,  and  then  prior  to  the  contact  management  display  by  the  sensor  operating 
assigning  a  coordinated  master  track  number  to  the  contact. 

The  most  common  activity  to  lead  to  error  in  correlating  tracks  is  due  to  human  error.  When 
accepting  a  visual  cut  to  a  hooked  track  (tracks  on  the  SAC  display  can  be  hooked,  in  which  case 
the  visual  cut  will  be  associated  with  the  hooked  track).  The  SAC  workstation  has  a  manual 
correlation  page  on  which  to  correlate  or  associate  tracks  that  have  been  passed  by  sensors 
without  being  associated  or  have  been  erroneously  accepted. 

The  SAC’s  decision  of  what  tracks  to  correlate  can  also  be  assisted  by  referring  to  the  Tactical 
Plan  Display  (TPD).  This  display  is  a  geospatial  display  showing  the  submarine’s  course,  as  well 
as  the  periscope’s  bearing  and  symbols  for  all  contacts  and  normally  displayed  on  an  adjacent 
console. 

3.3.5  Reassigning  Track  Numbers 

There  is  not  typically  a  need  to  reassign  track  numbers;  however  there  are  occasions  when  this  is 
necessary.  The  most  common  instance  of  reassigning  track  numbers  is  done  by  the  sonar 
operators  in  response  to  the  SACs  allocation  of  a  master  track  number.  The  other  situation  in 
which  track  number  may  be  reassigned  is  when  two  contact  bearings  are  going  to  cross.  In  this 
situation  the  system  may  get  confused  when  the  track  cross  and  assign  the  track  numbers  to  the 
wrong  contacts.  In  this  situation  the  SAC  must  monitor  the  tracks,  assume  a  contact  running 
straight  will  continue  running  straight  and  pay  particular  attention  to  the  amplifying  verbal 
information  passed  from  the  sound  room  and,  if  necessary,  swap  the  track  numbers  around. 

The  SAC  also  needs  to  ensure  that  the  track  numbers  have  remained  the  same  after  a  ranging 
manoeuvre.  Knowing  the  magnitude  of  the  ranging  manoeuvre,  the  sensor  operator  should 
correctly  reassign  the  master  track  number.  However,  the  SAC  must  verify  that  the  information 
has  been  maintained  correctly. 

3.3.6  Decluttering  the  Display 

Decluttering  the  display  (i.e.  clearing  the  display  of  information  that  is  of  no  interest  to  the 
operator)  is  not  done  except  in  the  case  of  contacts  whose  bearing  indicates  that  they  are  opening 
on  the  submarine  (i.e.  getting  further  away).  In  this  case,  the  SAC  will  request  permission  to  stop 
tracking  that  contact,  thus  decluttering  the  display. 
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3.3.7  Entering  Sensor  Data 


This  task  forms  much  of  the  SAC’s  job.  Although  the  SAC  should  enter  as  much  detail  about 
contacts  and  ship’s  activities  as  possible,  the  reality  is  that  SAC  typing  abilities  vary 
considerably.  Some  SAC  operators  have  memorized  key  strokes  and  sequences  to  enter  data  or 
access  menus  more  quickly.  This  memorization  is  made  easier  because  reports  are  provided  from 
the  sensor  in  a  standard  format  and  order,  facilitating  brevity  in  communication,  but  still  requiring 
transcription  by  the  SAC  operator  to  suit  the  contact  management  system. 

3.3.8  Communication 

As  noted  above,  communication  is  fairly  standardized  in  terms  of  its  format  and  order,  so  that  the 
team  has  expectations  regarding  communication,  thus  facilitating  the  identification  of  critical 
information.  The  radio  network  is  also  open  to  anyone  in  the  Action  Information  Organization,  so 
anyone  can  supply  amplifying  information,  such  as  knowledge  of  ship  capabilities  and 
dimensions,  ferry  schedules,  shipping  lanes,  etc.  Operators  also  have  to  contend  with  transposing 
alphabetical  characters  when  discussing  contacts,  to  numerical  characters  on  their  displays  and  in 
their  systems.  SMEs  wrote  the  ‘decode’  of  letters  to  numbers  in  grease  pencil  on  the  console, 
indicating  that  this  is  a  cognitive  overhead  that  is  particularly  prone  to  errors. 

Verbal  communication  is  the  source  of  much  of  the  most  useful  information  available  on  the 
submarine.  From  the  sound  room  they  receive  information  that  amplifies  a  contact  concerning  the 
number  of  blades  on  the  propeller,  imperfections  in  the  propeller  rotation,  and  other  characteristic 
acoustic  signals.  The  sound  room  will  also  pass  information  regarding  transients  and  biologicals 
(activity  outside  the  submarine,  based  on  actually  listening  to  the  sonar  feed),  which  can  be  loud 
or  can  be  weak,  but  generally  do  not  last  long  enough  to  be  caught  in  a  sonar  cut  and  thus  be 
passed  across  to  the  SAC.  Bearing  and  amplifying  information  will  also  be  provided  over  the 
voice  networks  by  the  ESM  operator  because  the  system  can  generate  a  large  number  of 
individual  tracks.  Therefore,  the  ESM  operator  manually/mentally  determines  the  average  of  the 
bearings  and  passes  the  information  verbally  to  the  SAC,  who  has  to  enter  the  bearing  manually. 
The  navigator  maintaining  and  monitoring  the  ECPINS  display  (onto  which  is  also  plotted  A1S 
data)  also  passes  data  verbally.  SAC  operators  will  often  jot  down  verbal  communications  onto  a 
piece  of  paper  and  enter  the  information  as  and  when  they  have  the  opportunity  (according  to 
workload). 

3.3.9  Consider  Contact  in  Relation  to  Critical  Safety  Parameters 

The  safety  of  the  submarine  is  the  responsibility  of  all  crew.  Anyone  in  the  Action  Information 
Organization  can  contribute  to  decision  making  regarding  safety,  irrespective  of  rank.  However, 
practically,  much  of  the  situation  awareness  for  safety  is  held  by  the  Officer  of  the  Watch 
(OOW),  watch  officers  and  Chief  of  Operations  (CHOPS).  These  crew  members  know  where  the 
submarine  is  in  relation  to  water  depth,  coastlines,  underwater  topographic  features,  territorial 
waters,  etc.  and  allow  a  comparison  of  the  tactical  picture  with  ground  truth.  Likewise,  the 
maintenance  of  situation  awareness  for  the  Go  Deep  Envelope  is  the  responsibility  of  the  crew 
member  on  the  periscope.  If  a  contact  suddenly  appears  close  to  the  submarine  unexpectedly  the 
periscope  operator  will  command  the  submarine  to  go  deep.  The  SAC  will  annotate  this  order. 
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The  SAC  will  also  annotate  significant  events  on  the  submarine,  such  a  fire,  and  will  listen  to  the 
damage  control  to  keep  that  information  updated. 

The  SAC  does  maintain  a  consideration  of  safety  with  respect  to  contacts  that  could  hit  or 
otherwise  kill  the  submarine,  and  what  the  submarine  could  hit.  Weapons-capable  contacts  are 
mentally  highlighted  by  the  SAC,  as  are  contacts  with  high  bearing  rates  because  they  are  close, 
visual  contacts  in  the  middle  of  the  ocean,  and  ‘abrupt-in’  contacts  (i.e.  contacts  that  seem  to 
appear  from  nowhere,  typically  fishing  vessels  when  they  start  their  engines  and  other 
submarines). 

It  is  likely  that  SMEs  set  thresholds  for  different  classes  of  contact.  These  thresholds  trigger  alerts 
when  met  or  exceeded.  These  may  be  thresholds  set  informally  by  the  SAC,  or  set  formally  by  the 
Captain  of  the  submarine.  One  example  provided  during  the  second  SME  session  concerned 
fishing  vessels  against  which  the  submarine  needs  to  maintain  a  certain  distance  for  safety  against 
possible  nets  or  lines  in  the  water.  As  with  bearing  rate  interpretation  above,  time  precluded 
specific  investigation  of  the  different  ship  specific  strategies. 

3.4  Requirements 

The  following  requirements  are  divided  into  four  main  sections;  these  sections  correspond  to  the 
top  level  ‘functional  purpose’  of  the  analysis.  They  are: 

•  Information  Management  Requirements; 

•  Sensor  Coordination  Requirements; 

•  Submarine  Safety  Requirements;  and, 

•  Mission  Achievement  Requirements. 

Note  that  the  nature  of  the  contact  management  task  is  sufficiently  integrated  and  seamless  that 
functional  purpose-related  requirements  could  reasonably  be  categorized  into  any  of  the  four 
purposes.  We  have  attempted  to  categorize  requirements  according  to  the  purpose  on  which  a 
requirement  would  have  the  clearest  impact. 

In  deriving  the  requirements,  the  constraints  imposed  by  both: 

•  The  limited  screen  area  being  targeted;  and, 

•  The  simple  re -hosting  of  the  fire  control  system,  rather  than  a  complete  re¬ 
implementation  of  the  software; 

were  respected.  All  requirements  fall  within  the  specific  constraints  on  design  options  for  this 
technical  refresh. 

Throughout  the  lists  of  requirements  ‘must’  was  used.  This  is  not  intended  to  imply  that  all 
requirements  must  be  met;  rather,  if  a  design  solution  touches  upon  an  area  that  makes  the 
requirement  relevant,  the  requirement  must  be  met.  Given  the  scope  of  the  technical  refresh  of  the 
FCS  system,  it  is  also  understood  that  cost-benefit  analysis  may  render  some  requirements 
unachievable,  even  if  they  are  pertinent  to  the  design  solution. 
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Additionally,  a  set  of  requirements  were  derived  concerning  the  impact  of  any  design  change  on 
system  performance  outcomes  (with  particular  emphasis  on  the  human  components  of  system 
performance). 

In  the  following  sections,  ‘the  system’  refers  solely  to  the  contact  management  time  and  bearing 
plot  display,  unless  otherwise  indicated. 

3.4.1  information  Management  Requirements 

•  The  ability  of  the  SAC  to  enter  information  into  the  contact  management  system 
must  be  improved  with  respect  to  items  of  information  entered  per  minute. 

•  The  reliance  on  memorization  of  key  sequences  must  be  reduced. 

•  The  need  to  maintain  a  temporary,  parallel  database  of  information  for  later  input  to 
the  system  must  be  eliminated. 

•  The  use  of  brevity  codes  must  be  exploited. 

•  The  standard  format  of  information  of  different  types  must  be  exploited  to  minimize 
keyboard  entry. 

•  The  information  management  system  must  present  sensor-  and  contact-type-specific 
data  entry  forms. 

•  The  sensor-  and  contact-type-specific  data  entry  forms  must  be  arranged  to  match 
the  format  of  the  standardized  verbal  reports  provided  to  the  SAC. 

•  The  information  management  system  must  reduce  the  breadth  and  depth  of  the  menu 
hierarchy  required  to  enter  information. 

•  The  system  must  support  both  alphabetical  and  numeric  track  identifications  (up  to 
and  including  full  words).  Reasonable  limits  to  the  number  of  characters  are 
acceptable. 

•  The  system  must  represent  ECP1NS  ‘ground  truth’  data,  concerning  geographic 
information  and  other  contextual/situational  cues,  as  well  as  the  representation  of 
the  growing  pool  of  errors. 

•  The  system  must  automatically  integrate  A1S  information  with  track  information  at 
the  SAC  position. 

•  The  system  must  allow  the  operator  to  ‘unpack’  a  track  into  its  constituent  sensor 
tracks  in  an  integrated  fashion  across  both  the  time  and  bearing  plot  and  the  tabular 
sensor  tracks  display. 

•  The  system  must  permit  the  user  to  control  any  automatic  or  manual  highlighting,  in 
particular  allowing  the  operator  to  turn  off  any  highlighting. 

3.4.2  Sensor  Coordination  Requirements 

•  The  system  must  highlight  sensor  data  that  has  been  entered  automatically  while  the 
SAC  has  been  fully  engaged  with  entering  data  from  another  sensor  suite. 


19 


3.4.3  Submarine  Safety  Requirements 

•  The  system  must  support  the  entry  and  automatic  comparison  of  safety  and  tactical 
parameters  (e.g.  alerts  for  speed,  range,  course,  bearing,  bearing  rate,  assigned  to 
contact  types  if  required)  against  contact  type,  range,  bearing,  course,  and  speed 
data,  for  the  purposes  of  highlighting  and  alerting. 

•  Any  presentation  of  safety-related  information  must  be  immediately  clear  to  the  user 
with  respect  to:  1)  its  presence,  2)  its  meaning,  and  3)  its  implications  for  the 
submarine. 

•  For  intermittent  contacts  the  system  must  indicate  the  range  of  possible  locations  at 
time  =  now,  and  time  =  user  defined. 

•  The  system  must  support  alerts  for  specific,  operator-selected  contacts. 

3.4.4  Mission  Achievement  Requirements 

•  The  system  must  support  user-initiated  highlighting  of  priority  contacts. 

•  Any  change  to  the  system  must  enhance  the  submarine’s  ability  to  achieve  the  aims 
of  the  mission,  remain  covert,  and  maintain  safety. 

•  The  system  should  extrapolate  to  indicate  when  the  CPA  of  a  contact  will  occur. 

3.4.5  Requirements  Concerning  the  Impact  of  Design  Options  on 
System  Performance 

•  The  proposed  change  must  make  it  easier  to  maintain  the  appropriate  data  update 
rate  for  contacts.  This  can  be  measured  by  whether  cuts  can  be  taken  quicker  and 
whether  information  can  be  entered  more  quickly. 

•  The  proposed  change  must  encourage  and  facilitate  the  recording  of  all  the  data 
possible.  This  will  be  measured  based  on  the  time  it  takes  to  enter  each  item  of  data, 
the  accuracy  of  data  entry. 

•  The  proposed  change  must  make  it  easier  to  relate  information  over  time,  develop 
expectations,  and  predict  the  likely  moves  of  the  contact.  This  may  be  measured 
during  scenario-based  investigations  (table-top  or  higher  fidelity)  based  on  direct 
questioning. 

•  The  proposed  change  must  assist  the  SAC  to  prioritize  the  attention  paid  to  different 
contacts.  This  will  be  measured  according  to  the  time  it  takes  to  prioritize  a  set  of 
contacts  and  the  adequacy  of  the  prioritization. 

•  The  proposed  change  must  make  it  easier  for  the  SAC  to  detect  changed  data, 
understand  what  the  data  is  telling  him,  and  predict  what  that  data  means  for  the 
future.  This  will  be  measured  by  detection  rates,  comprehension  speed,  and 
prediction  accuracy. 

•  The  proposed  change  must  make  it  easier  for  the  SAC  to  determine  how  to  employ 
the  different  submarine  sensors,  measured  in  time  to  decide  and  adequacy  of  the 
decision. 
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•  The  proposed  change  must  make  it  easier  to  develop  a  shared  awareness  of  the 
current  situation  and  the  priorities  of  the  situation  through  timely  and  accurate 
communication.  This  will  be  evaluated  by  comparing  knowledge  of  different  sensor 
operators  regarding  which  sensor  is  currently  the  priority,  what  sensor  will  be  the 
priority,  what  they  can  do  to  contribute  to  the  maintenance  and  updating  of  the 
contact  management  information,  and  what  contact  is  the  highest  priority. 

•  The  proposed  change  must  make  it  easier  to  consider  contacts  in  relation  to  the 
critical  safety  parameters  such  that  those  parameters  are  not  contravened.  This  will 
be  measured  by  evaluating  what  safety  parameters  are  contravened  how  often. 

•  The  proposed  change  must  increase  the  SACs  certainty  regarding  the  picture,  in 
particular  knowledge  regarding  bearing,  range,  course  and  speed  of  contacts. 
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4  Conclusion 


The  approach  taken  to  deriving  contact  management  requirements  resulted  in  30  requirements 
that  do  not  impose  design  solutions.  Within  these  requirements  there  are  some  clear  themes: 

•  The  method  by  which  the  SAC  inputs  information  to  the  system  is  laborious  and 
sub-optimal.  Several  requirements  concerned  the  improvement  of  the  data  entry 
process,  including  making  it  quicker,  enabling  the  use  of  alphabetical  characters  for 
track  identifiers,  and  developing  pre-formatted  and  standardized  data  entry  forms 
that  match  the  type  of  infonnation  to  be  entered. 

•  Situation  awareness  for  ‘ground  truth’  and  geographic  data  is  desired  by  SAC 
operators.  Adding  information  from  ECPINS  and  other  sources  as  a  supplemental 
verification  of  one’s  understanding  would  be  beneficial. 

•  The  setting  of  alerts  and  automatic  and  manual  highlighting  of  tracks  is  desirable. 

•  A  tote  of  priority  contacts,  whether  automatically  or  manually  determined,  would 
assist  situation  awareness. 

•  Any  design  option  must  be  evaluated  for  its  impact  on  system  performance, 
including  but  not  limited  to  speed  and  completeness  of  information  entered  into  the 
system,  situation  awareness  of  the  SAC  and  the  broader  Action  Information 
Organization,  ability  to  prioritize  contacts,  and  ability  to  effectively  use  sensors. 

In  carrying  out  this  work,  SMEs  provided  a  great  deal  of  design  suggestions.  However,  further 
work  will  be  required  to  fully  develop  design  options,  whether  corresponding  to  SME  suggestions 
or  to  address  a  requirement.  With  the  understanding  provided  by  carrying  out  this  analysis,  such 
design  work  could  be  accomplished  quickly  and  easily. 

Another  finding,  incidental  to  this  work,  concerns  the  analysis  method  employed.  The  CWA 
software  tool  obtained  from  Jenkins  et  al  (2006)  assisted  in  structuring  and  guiding  the  analysis 
process,  as  well  as  facilitating  the  completion  of  the  analysis  in  good  time.  A  number  of  usability 
issues  were  identified,  and  some  recommendations  for  improving  the  ability  of  the  analysis  to 
support  requirements  derivation  will  be  shared  with  the  authors  (Annex  C). 
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Annex  A  Abstraction  Hierarchy 


This  Annex  contains  the  AH  diagram,  as  well  as  tables  indicating  the  links  between  nodes  at  each 
level  of  the  AH.  The  AH  diagram  is  shown  in  Error!  Reference  source  not  found..  In  the  CWA 
Tool,  individual  nodes  can  be  selected  in  order  to  see  the  links  between  the  nodes,  using  red  lines. 
In  Error!  Reference  source  not  found.,  the  “RADAR”  node  in  the  physical  element  level  of  the 
AH  has  been  selected. 
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Annex  B  Contextual  Activity  Template 


The  Contextual  Activity  Template  is  shown  in  Figure  B-l.  In  the  CAT,  the  columns  represent 
situations,  and  the  rows  represent  object-oriented  processes  (or  functions).  The  likelihood  of 
occurrence  of  each  function  during  each  situation  is  represented  graphically.  A  function  that 
“can”  occur  during  a  situation  is  indicated  by  the  dotted  region,  while  a  function  that  “typically” 
occurs  is  indicated  by  the  box-and-whisker  diagram. 
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Figure  B-l:  Contextual  Activity  Template 


Annex  C  Usability  Notes  on  The  CWA  Tool 


The  notes  below  are  offered  as  observations  on  using  the  Human  Factors  Integration  Defence 
Technology  Centre’s  CWA  tool.  These  observations  are  made  without  communication  to  the 
creators  of  the  tool  and  may,  in  some  instances,  reflect  a  lack  of  understanding  of  how  the  tool  is 
intended  to  be  used. 

The  Abstraction  Hierarchy  does  not  automatically  scroll  while  making  links.  This 
means  that,  before  making  links,  the  user  needs  to  either: 

a)  Zoom  out  until  all  nodes  are  visible,  or 

b)  Alter  the  node  row  height,  node  width  or  node  height  so  all  nodes  are  visible. 

With  a  large  AH,  both  of  these  techniques  make  the  node  labels  too  small  or  too 
compressed  to  read  while  completing  the  links. 

The  Abstraction  Decomposition  Space  doesn’t  have  an  effective  way  to  deal  with 
multiple  subsystems  and  components.  Specifically,  a  system  will  be  comprised  of 
several  subsystems,  but  the  tool  only  allows  the  creation  of  a  single  subsystem  linked 
to  a  system.  Likewise,  a  single  sub-system  can  only  be  broken  down  to  a  single 
component.  There  should  be  a  way  to  create  multiple  subsystems  and  multiple 
components,  mapping  to  single  instances  at  a  higher  level. 

The  CAT  is  not  updated  along  with  the  AH.  When  functions  are  imported  into  the 
CAT,  they  are  not  linked  to  the  nodes  in  the  AH.  This  means  that  changes  to  the 
node  name  (for  Example)  would  need  to  be  made  manually  in  both  places. 

The  AH  provides  a  visual  overview  of  the  links,  but  there  is  no  way  to  get  a  tabular 
summary  of  links  from  the  tool.  This  would  be  a  useful  feature  for  summarizing  data. 
It  is  difficult  to  determine  the  links  from  the  AH  diagram  alone,  especially  in  large 
diagrams  with  many  links. 

Analysis  tools  would  be  useful,  for  instance  counting  the  number  of  links  between 
nodes  in  the  AH  (from  nodes  that  are  higher  in  the  AH  and  nodes  that  are  lower),  and 
counting  the  number  of  situations  a  particular  function  is  typically  done  or  can  be 
done. 

The  decision  ladders  shown  in  the  CAT-DL  are  too  small  to  be  meaningful. 

When  exporting  the  AH  diagram  to  a  JPG,  the  exported  file  will  also  show  a  node 
selected  and  red  links,  even  if  no  node  is  selected  when  the  export  is  selected.  It  is  not 
possible  to  export  an  AH  with  no  links  highlighted  (unless  there  are  no  links  in  the 
AH). 

Support  for  annotations  would  be  useful,  especially  when  defining  nodes  in  the  AH. 
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Support  for  tracking  requirements  throughout  the  entire  analysis  would  also  be 
useful.  Many  requirements  are  suggested  independently  in  separate  analysis,  and  it 
would  aid  traceability  to  maintain  a  master  list  of  requirements  that  could  be  linked  to 
discrete  points  in  the  analysis. 

Additional  online  help  regarding  the  intended  manner  in  which  the  tool  should  be 
used  would  be  beneficial.  An  included  complete  worked  example  with  suitable 
accompanying  background  material  would  help  users  understand  how  the  tool’s 
creators  expected  the  user  to  employ  to  tool  for  analysis. 

Note  that,  in  spite  of  these  observations,  the  CWA  tool  did  facilitate  the  derivation  of 
requirements  for  system  redesign.  Further,  it  facilitated  the  analysis  of  both  SME  sessions  and 
assisted  in  the  identification  of  particular  areas  to  address  during  the  second  SME  session.  The 
tool  also  assisted  in  the  communication  of  requirements  and  the  justification  of  these 
requirements  when  challenged. 
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List  of  symbols/abbreviations/acronyms/initialisms 


AH 

AIS 

BINT 

CAT 

CHOPS 

CPA 

CWA 

DMEPM(SM) 

DND 

DR  DC 

DRDKIM 

ECPINS 

ESM 

FCS 

GPS 

HGA 

LCMM 

MARS 

MPA 

NAVCOMM 

NCIOP 

R&D 

RCN 

SAC 

Abstraction  Hierarchy 

Automatic  Identification  System 

Basic  Intelligence 

Contextual  Activity  Template 

Chief  of  Operations 

Closest  Point  of  Approach 

Cognitive  Work  Analysis 

Directorate  of  Maritime  Engineering  Program  Management— Submarines 
Department  of  National  Defence 

Defence  Research  &  Development  Canada 

Director  Research  and  Development  Knowledge  and  Information  Management 
Electronic  Chart  Precise  Integrated  Navigation  System 

Electronic  Support  Measures 

Fire  Control  System 

Global  Positioning  System 

Hierarchical  Goal  Analysis 

Life  Cycle  Maintenance  Manager 

Maritime  Surface  and  Subsurface 

Maritime  Patrol  Aircraft 

Naval  Communicator 

Naval  Combat  Information  Operator 

Research  &  Development 

Royal  Canadian  Navy 

Sensor  Analysis  Coordinator;  also  called  Command  Display  Console  (CDC) 

SAR 

SME 

TG 

TMA 

TPD 

VCS 

operator 

Search  and  Rescue 

Subject  Matter  Expert 

Task  Group 

Target  Motion  Analysis 

Tactical  Plan  Display 

Victoria  Class  Submarine 
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